Method and apparatus for elapsed playback timekeeping of variable bit-rate digitally encoded audio data files

ABSTRACT

The present invention involves a digital audio player and a method for processing encoded digital audio data, wherein the digital audio data is encoded using one of a plurality of encoding formats. The audio data player has a hard disk or other data storage medium for storing data files, a microcontroller, buffer memory for anti-skip protection, and an audio decoder. The encoded audio data files and associated decoder files are downloaded from a personal computer or similar device to the audio data player hard drive. The player provides a menu-driven user interface for selection, sorting, and playback of stored audio data files. During playback, elapsed playback time is computed and displayed. For variable bit-rate audio data files, the audio data player generates an elapsed playback timekeeping map concurrently with playback and fast forward scan of audio data files. Concurrently with playback, forward scan, and reverse scan of the audio data file, the audio data player determines the compression ratio for each data portion traversed, and calculates a playback time for each data portion traversed.

This application claims the benefit, under 35 U.S.C. § 365 ofInternational Application PCT/US02/20364, filed Jun. 28, 2002, which waspublished in accordance with PCT Article 21(2) on Mar. 20, 2003 inEnglish and which claims the benefit of U.S. patent application No.60/317,573, filed Sep. 6, 2001.

BACKGROUND OF THE INVENTION

The present invention relates to an apparatus and a method forprocessing digitally encoded audio data and features of related musicmanagement software.

The use of portable audio data players capable of playing digitallyencoded audio data has become commonplace. In particular, relativelysmall handheld devices that can process digitally encoded audio datastored on solid state memory devices have become popular. Additionally,as demand has increased for higher data storage capacity in portableaudio data players, another generation of players has been developed andis gaining popularity. These portable audio data players includeminiaturized high capacity hard drives that are not as susceptible toskips and other similar problems as are typical hard drives used inpersonal computers (“PC”) and other applications.

In an audio data player, the digital audio data is loaded into a datastorage device by first downloading the data to a PC from an audio CD,the Internet, or another digital audio device. The data is then usuallycompressed according to a selected encoding format and loaded into thedata storage device associated with the audio data player.

The audio data is decompressed/decoded by the audio data player duringplayback according to the selected encoding format. A variety ofencoding formats for compressing and decompressing audio data isavailable. As used hereinafter, the term encoding format refers to anyencoding/decoding scheme that specifies the syntax and semantics of acompressed bitstream and how the bitstream must be decompressed forreproduction. Such encoding formats include, but are not limited to, MP3and MP3 Pro.

The data structure used for MP3 files include a sequence of interleavedheader frames and data frames. Each header frame includes various fieldsof information that pertain to the data frame that follows, for example,the bit rate used for compressing the data frame that follows. While thecompression ratio used for encoding the audio data file may be fixed(constant bit rate or “CBR”) or may vary frame to frame depending uponthe complexity of the audio (variable bit rate or “VBR”), the amount ofplayback time represented by each frame remains the same for MP3formatted files. Therefore, in a VBR file, the amount of data containedwithin each data frame will vary, thus presenting difficulties indisplaying elapsed play time during playback, especially when forward orbackward skipping during the playback of an audio data file. To solvethis problem, audio data players generally develop a timekeeping mapthat must be precompiled prior to playback by reading all of the headerframes of an audio data file. Unfortunately, the precompiling of atimekeeping map delays the commencement of playback once an audio datafile is selected.

For MP3 encoded audio data files, the data file is prepended or appendedwith a special set of frames called an ID3 tag. The ID3 tag containsdescriptive text and other data relevant to the audio data file. Forexample, the tag may include title, artist, album, year, comments, andgenre. ID3 tag information is useful for searching, sorting, andselecting specific audio data files based on the information containedin the ID3 tag. Because ID3 tag information is often stored as textualcharacters, the information can be displayed on the display screen of anaudio data player. Although such a user interface is useful for finding,selecting, and playing an individual audio data file, having to read thedisplay can be distracting to a person using an audio data player whileinvolved in an activity such as jogging or driving.

Most audio data players utilize a digital signal processor (“DSP”) forperforming audio decoding, decompression, and other transformations ofthe audio data file. For example, the DSP can provide various presetequalization modes or other audio enhancing settings that are useful forquickly selecting a specific playback preference. For example, a presetDSP mode may be specified for specific audio genres such as rock, jazz,and pop. Selection of such preset DSP modes generally requires the userto change the DSP mode during playback by pressing a designated buttonor selecting the DSP mode from a display menu.

Most PC-based audio data file management programs allow the user tocreate and edit playlists that can then be downloaded to a portableaudio data player and used for playing a select sequence of audio datafiles. One such form of playlist typically associated with MP3 audiodata files is known as an M3U list. An M3U playlist consists simply of atext file containing a numbered sequential list of paths or locations ofdata audio files included in the playlist. Thus, a playlist created on aPC and downloaded to an audio data player may be used to selectivelyplay a sequence of audio data files that are contained in the datastorage of the audio data player. However, audio data players generallydo not allow a playlist to be created or edited on the audio playeritself. Additionally, the M3U file format includes only the filelocation or path information and a comment field. Thus, the M3U fileformat does not contain other audio data file information such as theinformation contained in an ID3 tag of an MP3 audio data file.

BRIEF SUMMARY OF THE INVENTION

The present invention addresses some of the above-noted limitations ofaudio data players, particularly handheld audio players, by providing anaudio data player having a microcontroller coupled with data storage andan audio decoder for processing encoded audio data files and displayingthe elapsed time without pre-processing of the audio data. Inparticular, the present invention provides a method for calculating anddisplaying elapsed playback time of a variable bit-rate audio data file.The present invention also provides a method for generating an elapsedplayback timekeeping map during playback and fast forward scans modes ofaudio data files. Alternatively, the elapsed playback may be determinedby calculating the average forward bit-rate in combination with theamount of bits processed during the playback operation.

The audio data player generally includes a microcontroller coupled witha user interface, data storage, buffer memory, and an audio decoder. Theuser interface includes an LCD and a keyboard having various multi-wayand multi-function switches. The audio data player also provides auniversal serial bus (“USB”) port for connection to a PC or otherUSB-equipped device. By connecting the audio data player to a PC via theUSB port, audio data files and audio playlists can be downloaded to theaudio data player and stored into data storage. In one embodiment, thedata storage comprises a 10 GB hard drive; however, other moving datastorage media or solid state memory devices, such as flash memory cards,may also be used. In this embodiment, the user interface provides menudriven selection, sorting, and playback of audio data files.Additionally, during playback of an audio data file, the LCD displaysID3 tag information such as title, artist, album, and genre. The LCDscreen may also display other information such as elapsed playback time,volume level, and preset DSP mode.

The disclosed embodiment of the audio data player is a portable handheldunit having a rechargeable battery, 5 volt DC input, headphones outputport, and line out port. Therefore, the audio data player can be usedfor portable applications using headphones, or for fixed applicationsusing AC power and headphones or another audio device.

In one form thereof, a method is disclosed for monitoring in an audiodata player the elapsed playback time for an audio data file having dataportions capable of having different compression ratios, characterizedby, concurrently with playback, forward scan, and reverse scan of theaudio data file, determining the compression ratio for each data portiontraversed, and calculating a playback time for each data portiontraversed.

In another form thereof, in an audio data player comprising amicrocontroller coupled with data storage and an audio decoder, a methodis disclosed for displaying the elapsed playback time of an audio datafile, characterized by generating a timekeeping map concurrently withplayback and forward scan of the audio data file, and calculating anddisplaying an elapsed playback time concurrently with playback, forwardscan, and backward scan.

In yet another form thereof, an audio data player comprising amicrocontroller coupled with data storage and an audio decoder isdisclosed, characterized by the data storage storing audio data files, acircular buffer coupled to the data storage and buffering streaming ofaudio data, a timekeeper calculating an elapsed playback time for eachportion of audio data exiting the circular buffer (T1), a linear bufferreceiving data from the circular buffer, the linear buffer containing atime-length of audio data (ΔT), the audio decoder receiving data fromthe linear buffer, and the timekeeper calculating an elapsed playbacktime (T2) comprising the elapsed playback time for audio data exitingthe circular buffer (T1) minus the time-length of audio data containedin the linear buffer (ΔT).

Advantageously, the disclosed audio data player does not require thatthe entire audio data file be scanned for generating a timekeeping mapbefore beginning playback of the audio data file. Thus, the disclosedaudio data player does not have the delay after selecting an audio datafile for playback that is associated with precompiling a timekeepingmap. Additionally, generation of the timekeeping map does not requirethat the actual audio data be processed.

BRIEF DESCRIPTION OF THE DRAWINGS

The above mentioned and other features and objects of this invention,and the manner of attaining them, will become more apparent and theinvention itself will be better understood by reference to the followingdescription of one embodiment of the invention taken in conjunction withthe accompanying drawings, wherein:

FIG. 1 is a block schematic diagram of a portable audio data playeraccording to the present invention;

FIG. 2 is a top view of a portable audio data player according to thepresent invention;

FIG. 3 is a back view of the portable audio data player of FIG. 2;

FIG. 4 is the right side view of the portable audio data player of FIG.2;

FIG. 5 is a plan view of the main menu displayed on the audio dataplayer of FIG. 2;

FIG. 6 is a flowchart diagram illustrating the steps for playing back anaudio track using a portable audio data player according to the presentinvention;

FIG. 7 is a block diagram of data flow through a portion of the audiodata player of FIG. 2;

FIG. 8 is a flowchart diagram illustrating the steps for generating atimekeeping map and calculating and displaying an elapsed playback timein the forward modes;

FIG. 9 is a flowchart diagram illustrating the steps for generating atimekeeping map and calculating and displaying an elapsed playback timein the reverse modes; and

FIG. 10 is a flowchart diagram illustrating the steps for calculatingand displaying an elapsed playback time without generating a timekeepingmap.

Corresponding reference characters indicate corresponding partsthroughout the several views. Although the drawings representembodiments of the present invention, the drawings are not necessarilyto scale and certain features may be exaggerated in order to betterillustrate and explain the present invention. The exemplification setout herein illustrates one embodiment of the invention, in one form, andsuch exemplifications are not to be construed as limiting the scope ofthe invention in any manner.

DETAILED DESCRIPTION OF THE INVENTION

The embodiment disclosed below is not intended to be exhaustive or limitthe invention to the precise form disclosed in the following detaileddescription. Rather, the embodiment is chosen and described so thatothers skilled in the art may utilize its teachings.

FIG. 1 shows a block diagram of portable audio data player 10 accordingto the present invention. The general arrangement and operation of thevarious elements are described hereinbelow. However, the details of thevarious elements of audio data player 10 are well known to those skilledin the art and will not be discussed here. Audio data player 10comprises microcontroller 22 that controls the various elements and theoverall operation of audio data player 10, including transferring datafrom data storage 32, through buffer memory 25, and to audio decoder DSP12. Microcontroller 22 includes a suitable amount of memory 23, forstoring various instruction sets and programs for controlling theoperation of audio data player 10.

DSP 12 may be programmed to perform a variety of signal processingfunctions during playback of a selected audio data file. In this case,the functions that DSP 12 performs during playback include, but are notlimited to, decoding audio data files, volume control, digital soundequalization, and sample conversion. In that regard, DSP 12 includesonboard memory 1, wherein the decoder files, audio data files, equalizermode selection, and various other required data are loaded duringplayback.

The decoder files comprise programs that control the decoding operationsof DSP 12 and the audio data files include data associated with theaudio content. Both the audio data files and the decoder files may bestored in data storage 32. The decoder file including the programs aretransferred to DSP memory 11 from data storage 32. Alternatively, thedecoder files may be stored in ROM 23, RAM 11 or other suitable storagedevice of player 10. Further, the decoder files and other system filesand programs may also be stored in SDRAM 25, EEPROM 21 or other suitablestorage devices coupled to DSP12.

Audio data and decoder programs stored in data storage 32 may beencrypted, requiring that decoding program files and audio data files bedecrypted by DSP 12 using one or more decryption keys. The decryptionkeys may also be stored in data storage 32 and may be security linked tothe particular storage device or some other coded component of audiodata player 10 so that audio data files encrypted for use on aparticular audio data player may only be decrypted and played by thatparticular audio data player.

As a selected audio data file is decoded, DSP 12 provides the decodeddata stream to digital to analog converter 14. D/A converter 14 convertsthe digital output of DSP 12 into an analog signal and provides theanalog signal to headphones amplifier 16 and lineout pre-amp 40. Theanalog signals are amplified and provided to lineout jack 41 andheadphones jack 17, both disposed on housing 13 of audio player 10.

DSP 12 may include a plurality of selectable preset equalization modes,for example, bass, jazz, pop, rock, and flat. Each of these selectableequalization modes is specifically configured to enhance the audioreproduction of the type of audio information, such as the genre ofmusic or type of speaking that is encoded in the audio data.Additionally, the exemplary embodiment includes automatic selection ofthe DSP equalization mode and further allows the user to manually setthe sound equalization via a graphic equalizer user interface displayedon display 21 by LCD display module 20. Alternatively, player 10 mayadvantageously include a single IC that incorporates the functions ofmicrocontroller 22 and DSP 12 into one unit. An IC suitable for suchpurpose includes, but is not limited to, TMS320DA250 manufactured byTexas Instruments, Inc. Such an IC can be configured to decode andprocesses the MP3 files in the known manner, and also programmed toprovide the automatic DSP selection feature described below.

Audio player 10 is adapted to operate with data storage 32. In thisembodiment, data storage 32 is a moving data storage device,specifically a hard drive, that can be used to store various data files,including encoded audio data files, decoder files for controlling thedecoding operation of DSP 12, playlist files, and computer data files,such as, for example, word processing files, presentations, andspreadsheets. A large amount of data can be readily transferred betweendata storage 32 and microcontroller 22 through data bus 33. Buffermemory 25 operates as a circular data buffer to prevent interruption ofaudio playback caused by a skip or other similar moving data storagedevice data transfer delays. Using the present invention, decoder files,playlists, and relatively large amounts of audio data can be stored ondata storage 32.

In accordance with the present invention, audio data files are loadedinto data storage 32 via USB port 42 from a PC, or other similar device,using music management software that encodes the audio data files inaccordance with a selected encoding format, such as MP3, or MP3 Pro, andthen stores the encoded data files. Such music management software isimplemented using programming methods known in the art. The musicmanagement software transmits the audio data files and appropriatedecoder files to audio data player 10 across data buses 43 and 33 andinto data storage 32. The music management software also generates, andmodifies as necessary, a system configuration file and a file attributetable to provide information regarding the various data files anddecoder files stored in data storage 32. Using the configuration fileand the file attributes table, audio data player 10 is able to displayaudio data files sorted by various groupings on display 21, determinethe correct encoding format for each audio data file, and download theappropriate decoder file for each content file in response to a userselection.

FIGS. 2-4 illustrate an exemplary embodiment of the displays, buttons,switches, indicators, and ports which may be disposed on housing 13 ofaudio data player 10. Referring to FIG. 2, user input 26 comprises aplurality of buttons 44 (FIG. 3), 46 (FIG. 4), and 60-77 disposed onhousing 13 of audio data player 10 for allowing a user to sort andselect particular audio data files for playback, and to control playbacksettings. User input 26 may also comprise other input devices known inthe art, for example, keyboard, voice activated touch pad, and touchscreen input devices. Two multi-way switches comprise buttons 62-66 and68-72. Soft keys 74-77 are multi-function buttons whose function changefor various user interface menu displays. Audio data player 10 alsoincludes display 21 disposed on housing 13. Display 21 displays theaudio data files and playlists stored in data storage 32, the functionof soft keys 74-77, and various status information associated with audiodata player 10, such as the playback status shown in FIG. 2 and thetop-level menu shown in FIG. 5.

Referring again to FIG. 2, STOP/POWER button 60 allows the user to stopplayback and to turn audio data player 10 on and off. PLAY/PAUSE button62 allows the user to start playback and to pause playback. Left arrowbutton 63 allows a user to move a highlight left when using the menu,and to skip back to the previous audio data file or scan backward in thepresent audio data file when playing music. The right arrow button 65allows the user to move a highlight right when using the menu, skipforward to the next audio data file, and scan forward in the currentaudio data file when playing music. Up arrow button 64 allows the userto move the highlight up when using the menu. Down arrow button 66allows the user to move the highlight down when using the menu.

Referring still to FIG. 2, SELECT button 68 allows the user to select ahighlighted item. Volume up button 69 increases the playback volumelevel for headphones 18 and volume down button 71 decreases the volumelevel. MODE button 70 allows the user to select a particular playbackmode, including NORMAL, REPEAT, REPEAT ONE, REPEAT ALL, SHUFFLE, andREPEAT ALL SHUFFLE. SAVE button 72 allows a user to create a newplaylist or add audio data files to an existing playlist. Soft keys74-77 select the menu item that appears just above each button at thebottom of display 21.

Referring to FIG. 3, POWER indicator 78 lights when audio data player 10is on. CHARGE indicator 79 lights when the power source 47 is charging.In the exemplary embodiment, power source 47 is a rechargeable batterypack. DC IN jack 48 provides 5 volt DC from an AC adapter to power audiodata player 10 and recharge power source 47. RESET button 44 allows theuser to reset all of the audio data player settings to the factorydefaults.

Referring now to FIG. 4, OFF/LOCK switch 46 allows the user to makebuttons 60-77 inactive when switch 46 is slid to the locked position.LINE OUT jack 41 allows a user to connect the audio data player to aseparate audio system. Headphones jack 17 allows the user to play thedecoded audio on headphones 18. USB port 42 provides connection of audiodata player 10 to a PC or other similar device using a USB cable.

When the user selects a particular audio data file for playback via userinput, microcontroller 22 loads the appropriate decoder file associatedwith the selected audio data file from data storage 32 into DSP memory1. Referring again to FIG. 1, microcontroller 22 then streams theselected audio data file along buses 33 and 29 into DSP 12, using buffermemory 25 as a skip-protection buffer.

After streaming of the selected audio data file begins, DSP 12 decodesthe audio data file using the associated decoder file. The decoder filesstored in data storage 32 allow audio player 10 to be adapted to processthe various encoding formats associated with the audio data files storedin data storage 32. In effect, portable audio player 10 is softwareupgraded, as necessary, by the decoder files stored in data storage 32when the user selects a particular audio data file stored in datastorage 32. The steps associated with processing a selected audio datafile from data storage 32 using audio data player 10 is shown in theflowchart of FIG. 6, and described below.

FIG. 6 shows a flowchart illustrating the steps for processing aselected audio data file in accordance with the present invention. Afterpowering up in step 100, microcontroller 22 of audio data player 10loads the system configuration file from data storage 32, in step 110.Also in step 110, microcontroller 22 identifies the various file formatsthat need to be supported for the data files stored in data storage 32.The configuration file also includes information that equates the fileextension of the audio data files with particular decoder files storedin data storage 32. In step 120, if a configuration file is not valid,microcontroller 22 causes an error indication to be displayed, step 122,on display 21. In step 124, if the configuration file is valid,microcontroller 22 reads the file attribute table stored in data storage32 and causes display 21 to display a menu-driven listing of thefile/folders stored in data storage 32.

Referring to FIG. 5, the main menu displayed on display 21 allows theuser to navigate and display audio data files according to groupings oridentifying characteristics, such as, for example, artist, album, title,genre, playlist, and all audio data files. From the main menu, the usermay operate user input 26, as described above, to navigate sorted listsand select a desired one of the displayed audio data files or playlistsfor playback.

When an audio data file or playlist is selected for playback in step126, microcontroller 22 and DSP 12 perform a number of steps, includingseveral concurrent steps, to provide audio playback. First,microcontroller 22 identifies and transfers the corresponding decoderfile from data storage 32 to DSP memory 11 in step 130. For example, ifthe user selects an MP3 file, microcontroller 22 transfers the MP3decoder file from data storage 32 to DSP memory 11. The MP3 decoder fileis used to control the decoding operation of DSP 12.

In step 132, microcontroller 22 begins streaming the selected audio datafile from data storage 32 through buffer memory 25 to DSP 12. In step134, DSP 12 uses the decoder file to decode and decrypt, if applicable,the audio data file in accordance with the appropriate encoding format.The decoded audio data is provided to D/A converter 14 and headphone amp16 and line out pre amp 40 for reproduction.

In step 136, it is determined whether all of the data in the selectedaudio data file has been transferred to buffer memory 25. If not, instep 138, microcontroller 22 continues to stream data from data storage32 to buffer memory 25. If the transfer of data is complete asdetermined in step 136, microcontroller 22 determines in step 140whether the next audio data file is encoded using the same format as theprevious audio data file. If the encoding format of the next audio datafile is the same as the previous encoding format, microcontroller 22returns to step 132 and starts streaming the data from the next audiodata file, which data is subsequently decoded in step 134 as before.

If the encoding format of the next audio data file differs from theencoding format of the previous audio data file, microcontroller 22returns to step 130. In this case, a new decoder file associated withthe next audio data file is transferred to DSP memory 11, and the stepsof streaming the audio data file and decoding the data file using thenewly loaded decoder file is repeated. In this manner, audio data player10 is able to playback audio data files encoded using any one of aplurality of encoding formats, as long as the decoder file associatedwith the selected encoding format is available and can be downloadedonto DSP memory 11. In the present embodiment, the necessary decoderfiles are stored in data storage 32 along with the audio data files. Assuch, audio player 10 can be updated to play different encoding formatsby software updating of the DSP via decoder files stored along with theaudio data files in data storage 32. Thus, audio data player 10 iscapable of playing back data files encoded using a variety of encodingformats, including encoding formats that become available in the future.

During playback display, shown in FIG. 2, displays various informationabout the audio data file and the audio data player settings. Forexample, display 21 in FIG. 2 shows the file name, artist name, albumtitle, genre, current track being played out of total files beingplayed, volume level indication, elapsed play time of audio data file,playback mode indication, bit rate, and selected DSP mode selection.

Referring to FIG. 7, the exemplary embodiment of audio data player 10generates a playback timekeeping map concurrently with playback and fastforward scan of an audio data file. Additionally, audio data player 10calculates and displays an elapsed playback time concurrently withplayback, forward scan, and backward scan of an audio data file. As anaudio data file is streamed from data storage 32 through buffer memoryor circular buffer 25, microcontroller or timekeeper 22 calculates anelapsed playback time, T1, for each segment of audio data. As DSP memoryor linear buffer 11 receives the audio data stream from circular buffer25, linear buffer 11 contains a time length, ΔT, of audio data. In orderto calculate and display the elapsed playback time, T2, for the dataleaving linear buffer 11 and entering DSP decoder 12 for decoding,timekeeper 11 subtracts the time length ΔT of audio data contained inlinear buffer 11 from the elapsed playback time of audio data exitingcircular buffer 25, T1. Thus, T2 represents the elapsed playback time ofthe audio data file for the audio data currently being decoded by DSP12.

In the exemplary embodiment, although audio data is stored in dataframes that vary in length depending on the compression ratio,timekeeping is performed for each data segment, specifically, for each512 byte sector. Therefore, playback time for each sector or segment ofdata is calculated. If a sector boundary falls within a data frame, thetimes at the ends of the frame may be interpolated as desired.

The timekeeping map or data structure in the exemplary embodiment storesthe playback time in milliseconds for each 64 sector block of datarather than for each sector of data. Therefore, an estimate of theplayback time of a whole block is calculated and stored as each datasector is processed. Thus, the timekeeping map includes a playback timereference for every sector that has been processed, even if the entireblock has not been processed. Advantageously, the timekeeping map can begenerated without processing the actual audio data. Additionally, theblock times may be stored in a 4,096 word (16 bits per word) circularbuffer that represents about an hour of typical MP3 file playback time.

In the processes according to the present invention, the compressionratio or bit-rate for the data frame following the header frame is firstread. Because timekeeping is performed in units of sectors in theexemplary embodiment, playback time is calculated per sector, T_(S). Asingle MP3 data frame may be smaller or larger than one 512 byte sector,thus interpolation is completed as desired to calculate the playtime persector, T_(S). Additionally, because playback times are stored in thetimekeeper map by data blocks of 64 sectors each, the present inventioncalculates the playback time per block, T_(B). The playback time T_(B)is calculated for the current block for each data sector processed, sothat a playback time is available for each sector as it is processedrather than after each block is completed. Playback time T_(B) for thecurrent block is stored in the timekeeper map in circular buffer 25. Theprocess is then repeated for the next data segment.

For each data sector traversed forwards or backwards, the processcalculates and displays the elapsed playback time of the audio datafile. Specifically, the present invention retrieves the playback timeT_(B) for the data block, which contains the current data sector. Theelapsed playback time T1 is incrementally added to or subtracted fromfor the playback time of the current data sector being traversed. Thus,the playback time for the current data block is multiplied by the numberof blocks, which is 1/64, because in the exemplary embodiment there are64 sectors per block. The sector playback time is then added to theelapsed playback time T1 for playback or forward scan mode, orsubtracted from T1 for backward scan mode (T2=T1±T_(B)*(# of blocks)).The playback time T1 is adjusted for the time length of the dataresiding in linear buffer 11, ΔT, which is equal to the size of linearbuffer 11 in blocks multiplied by T_(B)(T2=T1−ΔT; ΔT=size of linearbuffer in blocks *T_(B)). Thus, T2 represents the elapsed playback timeof the audio data currently being transited and present at DSP 12.Elapsed playback time T2 is then displayed on a display device of audiodata player 10.

In the exemplary embodiment of audio data player 10, small chunks offorward play alternate with large chunks of backward skipping duringbackward scan mode. Thus, during both the traversing of data duringforward play and backward skips, audio data player 10 adds and subtractsthe estimates of playback time being traversed in accordance with theflowcharts shown in FIGS. 8 and 9. Additionally, the present timekeepingmethod may also be used with a repeat A/B feature. As playback of anaudio data file proceeds, the user can select a point A, where arepeat-interval will begin, and a point B, where the repeat-intervalwill end. When the user selects point A, the audio data file position insectors is stored and the estimated elapsed playback time inmilliseconds is stored. Whenever playback of the audio data file skipsfrom point B back to point A, the elapsed playback time is reset to thestored value and playback proceeds forward from point A, timekeeping inaccordance with the manner described below.

The processes according to the present invention are now described morespecifically below. Referring to FIG. 8, a flowchart of the process forgenerating a timekeeping map concurrently with playback and forward scanmodes is shown. In step 804, a next sample/segment of the data, in thiscase one byte of data, is loaded into a buffer. In step 806 it isdetermined whether an end of the data file has been reached by loadingthe byte of data into the buffer. If so, the process ends at step 808.Otherwise, the process determines whether a frame header has been loadedinto the buffer by the most recent loading of the data segment in step810. It is determined whether a frame has been loaded by comparing thebit sequence with that associated with the frame header. If the bufferdoes not have a frame header, the process continues to step 812 toadvance by one data sample/segment and then to step 824 to determinewhether there has been any change in the operating mode, for example, bychanging to a reverse mode. If a reverse mode has been selected, theprocess enters into a procedure for determining the elapsed time in thereverse mode as shown in FIG. 9.

If a frame header has been loaded into the buffer as determined in step810, the 816 and calculates the time elapsed for each block of data instep 818. Recall that the time process reads the frame bitrate in step814, calculates the time elapsed for each sector in step elapsed perframe is a constant for a given file. Therefore, the time for a sectormay be taken to be the number of frame headers in the sector multipliedby the constant time per frame. As the process traverses the sectors ina given block, the process keeps a running count of the time so far inthe block, and the number of sectors so far in the block. Then toestimate the block time, the process multiplies the sum of frame timesby 64, and divides by the number of sectors so far in the block. Notethat for the final sector of the block, this estimate of block time isexact, and this is the final estimate entered in the map. In step 820,the process generates a timekeeping map from the calculated values andstores the data. In step 822, the system advances a predetermined amountof data to a point that is nearly the next frame header start. Eachframe size is known from parameters given in its header. It isadvantageous to advance to nearly the next header to avoid potentialfalse header codes in the data, and the to save computing time inverifying the header codes where the likelihood of the presence of aheader code is very low.

Again, in step 824, the step determines whether the operating mode hasbeen changed from the forward operating mode. If so, the process goes tostep 826 and executes the steps for determining and displaying theelapsed time according to FIG. 9. If the operating mode has not beenchanged, the system proceeds to the beginning of the process to step 804to repeat the above-described steps. Another aid to avoiding falseheader codes can be to generate a confidence measure indicative of theconfidence that a series of true headers has been acquired. When theconfidence measure is quite low, the process may be configured toreplace step 822 with the step of advancing only one segment/sample, asin step 812. The process should also check for parameters given inheaders that can vary between files, but that must be constant for anygiven file. These efforts maximize the chances of acquiring the seriesof true headers quickly.

FIG. 9 illustrates the steps for determining and displaying the elapsedtime when the player is operating in the reverse mode. In the reversemode, the player operates by going back in reverse a predeterminedamount and then going forward for a certain fragment in order to obtainthe necessary data for determine the elapsed time. The process, in step904 advances or retreats one sector. In step 906, the process retrievesthe time per data block and in step 908 determines the time per sectorby dividing the time per data block by 64. In step 912, the processdetermines whether the data has been accessed in the forward or reversedirection. If in the reverse direction, the time per sector issubtracted from the current elapsed time, and in the forward direction,the time per sector is added to the current elapsed time. In step 916,the process determines whether a start of data has been reached. If thestart of data has been reached, the process leaves the reverse mode instep 920 and exits to forward processing in step 922. If the start ofdata has not been reached, the player determines whether a change ofoperating mode has been requested, for example, by changing to theforward mode. If the forward mode has been determined in step 918, theprocess exits to the forward processing mode in step 922. If the forwardmode has not determined in step 918, the process returns to thebeginning of the procedure by returning to step 904. In this manner, theelapsed time is determined during the reverse mode of operation. Notethat the estimated time for each sector is only an approximation, butthat whenever a complete block the elapsed time calculated for thatblock is exact.

FIG. 10 illustrates the steps for determining the elapsed time, withoutcreating a timekeeping map when player 10 is operating in either theforward or reverse modes. In step 1004 the process determines whetherthe player is in the forward or reverse mode. If in the forward mode, orthe normal-play mode, the process continues to step 1006, wherein theelapsed time is determined using a clock included in player 10. In step1010, the process updates the total forward time. In step 1016, theprocess reads the amount of data processed, and in step 1022 the processupdates the total amount of data processed in the forward direction. Instep 1024, the average forward bitrate is (“AFB”) computed. The processcomputes the AFB to be the sum total for all bits traversed in normalplay divided by the sum total of all the times it took to traverse thosebits. Alternatively, the process may calculate the AFB using a weightedapproach, wherein a predetermined number of bits immediately prior tothe calculation and the sum total of time associated with that number ofbits may be more heavily weighted in the calculation that bits that aremore distant in time. If normal play has not yet occurred, and fastforward has been started from the beginning of the file, the process maybegin with a predetermined estimate of the average bitrate. For MP3files, this is typically 128 kilobits per second. In step 1026, theprocess determines whether playback of the selected file is completed.If so, the process ends at step 1028, and if not, the process repeatsfrom step 1004.

If in step 1004 it is determined that the player is not operating in thereverse mode, the process continues to step 1008 to determine whetherthe player is currently processing the data in the forward or reversedirection. If the data is not being processed in the reverse directions,the process reads the amount of data advanced in step 1012 anddetermines the change in time by dividing the amount of data advanced bythe average forward bit rate determined in step 1024. If the data isbeing processed in the reverse direction, as determined in step 1008,the process reads the amount of data retreated in step 1014 anddetermines the change in elapsed time by dividing the amount of dataretreated by the average forward bit rate. Again, it is determined instep 1026 whether the processing of the data of the selected file iscompleted. If so, the process ends at step 1028, and if not, the processrepeats from step 1004.

Although the above-described timekeeping method does not require atimekeeping map to be precompiled before playback and therefore it doesnot require an extra pass through the audio data file, an embodiment ofthe present invention may also include a method of compiling atimekeeping map that is compiled prior to playback. A precompiledtimekeeping map allows playback of the audio data to begin well into theaudio data file. Additionally, it allows faster forward scanning of theaudio data file in the event that DSP 12 is limited by the rate at whichit can read the audio data file.

Calculations and experiments have shown that having an average mappingratio of 10 seconds per 16 bit map word keeps timekeeping close to theone second time precision typical of timekeeping. Since this mappingratio is about two bits per second, the typical audio data file requiresa timekeeping map or data structure of only at least about four ordersof magnitude smaller than the audio data file being mapped.

In the exemplary embodiment, suitable microcontrollers 22 include, butare not limited to, μPC78A4036 manufactured by NEC Corporation.Associated with microcontroller 22 is memory 23, in this case, 48 KB ofROM, and buffer memory 25 comprising 8 MB of RAM, providing 7 minutes ofbuffered play time at 128 kbps and 14 minutes of buffered play time at64 kbps. Suitable DSP units 12 include, but are not limited to,TMS320NC5410 manufactured by Texas Instruments, Inc., of Dallas, Tex.DSP 12 also includes associated memory 11, in this case 64 KB of RAM.Suitable hard drives for data storage 32 include, but are not limitedto, Microdrive™ manufactured by IBM Corporation of Armonk, N.Y. A 10 GBhard drive, for example, provides approximately 150 hours of audio atMP3 bit-rate of 128 kbps, or 300 hours at a bit-rate of 64 kbps.

It will be apparent to those skilled in the art that although thepresent invention has been described in terms of an exemplaryembodiment, modifications and changes may be made to the disclosedembodiment without departing from the essence of the invention. Forexample, although the present invention has been described withreference to data storage 32 that is fixedly disposed within audioplayer 10, the present invention may be implemented using flash memory,another fixed storage device, optical device, or a memory card that isadapted to be coupled, either detachably or fixedly, to audio player 10,wherein the decoder program and audio data files are loaded onto thememory card by the music management software. Also, it is hereinrecognized that the present feature of loading the appropriate decoderprograms and the audio data files may be implemented in the musicmanagement software using any one of a number of conventionally knownprogramming methods, or combination of programming methods. Also,although the above is described in reference to an audio data player,the present invention may be extended to any portable data processingdevice, for example, video display devices, wherein the data may beencoded using one of a plurality of data encoding formats. Therefore, itis to be understood that the present invention is intended to cover allmodifications as defined in the appended claims.

1. A method for monitoring in an audio data player, during theprocessing of an audio data file having data portions capable of havingdifferent compression ratios, the elapsed playback for the audio datafile, comprising the steps of: determining the compression ratio andsize of each data portion traversed; calculating the playback time foreach data portion traversed based on the compression ratio and size ofeach data portion traversed; and displaying the playback time on adisplay of the audio data player in response to the calculation.
 2. Themethod of claim 1, wherein the determining step comprises determiningelapsed time within the current data portion by interpolation.
 3. Themethod of claim 1, further including the step of storing the playbacktime for each data portion traversed in a timekeeping map.
 4. The methodof claim 1, further including the step of adjusting an elapsed playbacktime counter based on the playback time for each data portion traversed.5. The method of claim 1, wherein the calculating step comprisescalculating elapsed playback time at an input to a buffer feeding anaudio data decoder; and the elapsed playback time is adjusted bysubtracting an estimated playback time of the data contained in thebuffer.
 6. The method of claim 1, wherein the compression ratio isdetermined based on the bit rate stored in data frame headers of theaudio data file; and a confidence estimator locates frame headers andthereby locates the bit rate.
 7. The method of claim 1, wherein thecompression ratio is determined based on the bit rate stored in dataframe headers of the audio data file; and an interval skipper locatesframe headers and thereby locates the bit rate.
 8. The method of claim1, wherein each data portion includes a fixed time length of audio dataand a variable length of data, the length of data being determined bythe compression ratio for each data portion.